📚 Hub Books: Онлайн-чтение книгДомашняяСоздаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

Создаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

Шрифт:

-
+

Интервал:

-
+
1 ... 110 111 112 113 114 115 116 117 118 ... 195
Перейти на страницу:
в самом начале гипотезы: удается ли реализовать все главные механики игры и будут ли они интересными.

Конечно, далеко не все механики нужно проверять сейчас. Нам необходимо определить приоритеты: какие из них действительно важны, а какие второстепенны. Если игра является аркадой, шутером или гонкой, то управление – ее основная часть, и именно на этой механике нужно сосредоточиться. В игре еще останется место для второстепенных механик, но их отдельным изучением и прототипированием можно будет заняться позже, даже во время этапа производства игры, в более спокойной обстановке.

Этап прототипирования механик самостоятелен, и к нему можно обращаться в любой момент в процессе разработки игры. Например, если наша игра предназначена для мобильных устройств, то, скорее всего, мы вообще захотим выпустить ее в свет задолго до окончания работы над всеми задуманными механиками. В таком случае не надо спешить и тратить время на прототипирование всех возможных механик.

Также не стоит проверять механики, в которых мы уверены, например когда у нас уже есть опыт реализации этих элементов. То есть процесс проверки предназначен для действительно оригинальных вещей, которые либо нигде раньше не встречались и нет возможности удостовериться в их интересности на чужом опыте, либо мы еще не знаем, как именно их реализовывать.

«Бумажный прототип» – это метод разработки механик, программного обеспечения, гейм-дизайна, когда на бумаге создаются наброски от руки. Отсюда и название. Это может быть также настольная игра. Бумажный прототип позволяет проверить гипотезы и идеи реализации продукта, не прибегая к дорогим методам разработки на первоначальном этапе.

Сама проверка механики необязательно должна выливаться в написание кода. Мы можем проверить ее, например, в виде настольной игры. Особенно если нашей задачей является проверка того, насколько механика интересна, а не какова возможность ее реализации. Такая настольная игра может быть сделана буквально «на коленке»: можно взять бумагу из тетради или принтера, нарисовать карту, вырезать карточки действий и персонажей. Генератор случайных чисел в виде игрального кубика можно взять из другой настольной игры или найти в интернете.

* * *

Например, мы работаем над игрой о мусороперерабатывающей фабрике. Мы можем создать карту с рабочими местами, на которых расставим персонажей. Одни персонажи лучше сортируют, другие лучше управляются с техникой. Каждый цикл мусор, находящийся на фабрике, перемещается от одного персонажа к другому, и на фабрику прибывают новые грузовики с мусором. Если игрок правильно расставил персонажей, то мусор будет перерабатываться эффективно и не будет накапливаться. Если к концу раунда на фабрике останется не отсортированный мусор, можем считать это проигрышем, хотя это совершенно не важно. Ведь на этом этапе мы проверяем интересность самого игрового процесса, а не придуманные на скорую руку правила и баланс.

Итак, нам нужно немножко поработать руками.

• Так как фабрика, по сути, разделена на отдельные зоны, в которых работают отдельные персонажи, эти зоны у нас будут изображать листы бумаги с названиями зон. Пока зон у нас будет две: зона разгрузки и зона сортировки.

• У нас будет набор карточек с персонажами с разными случайными характеристиками. Карточки мы вырежем из той же бумаги, напишем на них имена персонажей, нарисуем портреты и распишем характеристики. Кому-то достанется +2 на сортировку стекла, кому-то +5 на управление погрузчиком и т. п. Мы можем сделать с десяток таких карточек и ограничим игрока правилом, что из персонажей он может взять только троих случайных. Двух можно поставить в зону сортировки, а одного на разгрузку.

• Мусор у нас будет в виде фишек – клочков бумаги с разными обозначениями: С – стекло, Б – бумага и т. п. Таких фишек нам нужно штук 50.

Дальше идет сам игровой процесс.

• Вначале игрок кидает игральный шестигранный кубик, чтобы узнать, сколько мусора придет ему на фабрику в начале хода. Соответствующее выпавшему числу количество мусора нужно взять из мешка с мусором случайным образом. Мусор попадает в зону разгрузки, при этом он должен оставаться скрытым для игрока, а значит, лежать «рубашкой» вверх.

– Скрытость мусора – это довольно важное уточнение, о котором мы могли не подумать с первого раза. Если мы случайно нарисуем обозначение мусора на обеих сторонах фишки, то нам придется их переделывать. Это маленький урок итеративности.

• Отвечающий за разгрузку персонаж должен переправить мусор из зоны разгрузки в зону сортировки. Перевезти персонаж может столько мусора, сколько очков управления погрузчиком у него есть. Пока мусор скрыт, игрок может взять любые фишки мусора и переложить их в зону сортировки.

– Уже здесь можно немного задуматься над балансом игры. Игроку в начале хода может прийти и одна единица мусора, и шесть. Иногда игроку будет приходить меньше мусора, чем он может перевезти, а иногда больше. Тогда мусор начнет накапливаться в зоне разгрузки. В среднем d6 будет давать значение 3,5. Соответственно ставить на разгрузку персонажа с навыком меньше 4 довольно рискованно.

• В зоне сортировки мусор можно раскрыть и перевернуть. Сортировщики работают примерно по тому же принципу, что и погрузчик: игрок может переместить столько мусора, сколько очков есть у персонажей, находящихся в зоне сортировки. Если у нас есть два персонажа: на 2 очка стекла и 3 очка стекла – значит, суммарно за ход игрок может отсортировать 5 единиц стекла.

* * *

На этом этапе еще нет никакой объективной оценки интересности. Эту настольную игру мы можем показать в лучшем случае коллегам. Но мы уже можем начать работать с отзывами. Немного поправить правила, изменить количество типов мусора, количество персонажей. Исправить ошибку с забытым правилом, что на разгрузку мусор должен попадать скрытым от игрока. Этап разработки прототипа даже отдельной механики так же итеративен, как и весь процесс разработки игры как программного продукта:

• создаем новую версию;

• тестируем;

• получаем отклик;

• повторяем до тех пор, пока отклик не будет достаточно позитивным.

Важно понимать, что идеальный результат, скорее всего, недостижим. С одной стороны, мы всегда будем ограничены в ресурсах и у нас не будет возможности бесконечно полировать игру, а с другой стороны, удовлетворить всех невозможно. Когда-нибудь придется сделать выбор и остановиться на достигнутом, даже если результат не кажется идеальным.

Естественно, проверка касается не только механики менеджмента в стратегической игре об управлении мусорной фабрикой, но и любых других механик, которые будут играть важную роль в нашей игре. Если наша игра является аркадой, то мы должны хотя бы приблизиться к удовлетворяющему нас управлению персонажем и камерой. У нас еще будет возможность отполировать их.

На этом этапе у нас пока еще нет ничего, кроме механик. Нет графики, звуков.

Интерфейсы пребывают в зачаточном состоянии и выполняют только базовые, тестовые функции.

Производство графики для игры – процесс

1 ... 110 111 112 113 114 115 116 117 118 ... 195
Перейти на страницу:

Комментарии

Обратите внимание, что комментарий должен быть не короче 20 символов. Покажите уважение к себе и другим пользователям!

Никто еще не прокомментировал. Хотите быть первым, кто выскажется?